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Abstract 
This document updates version 1.1.0 of the Network Solutions Inc. 
(NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The 
changes described in this document combined with the base 
specification documented in RFC 2832 specify version 2.0.0 of the 
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Introduction 


The Network Solutions, Inc. (NSI) Registry Registrar Protocol (RRP) 
was developed by NSI in 1998 and 1999 to allow multiple registrars to 
provide second level Internet domain name registration services in 
the top level domains (TLDs) administered by the NSI TLD registry. 
Version 1.1.0 of the NSI RRP was published as Informational RFC 2832 
[2] in May 2000. This document describes changes to RFC 2832 that 
specify version 2.0.0 of the protocol. 


Conventions Used In This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 


NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
in this document are to be interpreted as described in BCP 14, RFC 


2119 [1]. 
In examples, "C:" represents lines sent by a protocol client and 
"S:" represents lines returned by a protocol server. 


Protocol Updates 


This specification describes several modifications to RFC 2832 [2]: 
two new response codes have been added, domain TRANSFER command 
processing has been updated to allow a client to cancel a requested 
domain transfer, and support for IPv6 name server addresses has been 
added. 


1. Response Codes 


Section 5.1 of RFC 2832 [2] has been updated to include two 
additional error response codes. 


510 Invalid encoding 


The value of a domain name or name server entity contains invalid 
ASCII compatible encoding used to represent an internationalized 
domain or host name. The encoding is checked and verified in two 
situations: when registering an internationalized domain name or name 
server name, and when changing the name of a name server and the new 
name of the server is internationalized. 
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Section 5.2 of RFC 2832 [2] has been updated to include response code 
510 as a possible error value returned from the ADD command: 


Command: ADD 

Success: 200, 220 

Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 
535, 540, 541, 545, 546, 547, 549, 550, 554 


557 Name server locked 


An attempt has been made to modify or delete a name server that is 
hosting a TLD in the root zone. Modifications to the root zone can 
only be made with the approval of the U.S. Department of Commerce and 
IANA, so if the registrar absolutely needs to modify or delete such a 
name server, the action needs to be coordinated through the registry 
operator using an out-of-band communications channel. 


Section 5.2 of RFC 2832 [2] has been updated to include response code 
557 as a possible error value returned from the DEL and MOD commands: 


Command: DEL 

Success: 200, 220 

Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, 
533; 541, 1544, 5459; 547, 5497 5514-5527 553, 557 


Command: MOD 

Success: 200, 220 

Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 
535, 540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553, 557 


.2. TRANSFER Command Update 


Section 4.3.10 of RFC 2832 [2] has been updated to include an 
additional TRANSFER command processing option. 


Old text: 


Authorized User: All registrars MAY use the TRANSFER command to 
request the transfer of registration service authority to the 
requesting registrar. Only the current sponsoring registrar of a 
domain name may explicitly approve or reject a requested transfer. 
The registry MAY implicitly approve or reject requested transfers 
after a fixed amount of time. 
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New text: 


Authorized User: All registrars MAY use the TRANSFER command to 
request transfer of registration service authority to the requesting 
registrar. Only the current sponsoring registrar of a domain name 
may explicitly approve a requested transfer. The current sponsoring 
registrar MAY explicitly reject a requested transfer. The registry 
MAY implicitly approve or reject requested transfers after a fixed 
amount of time. The requesting registrar MAY cancel a pending 
request, but the request to cancel the transfer MUST be sent before 
it has been explicitly approved or rejected by the current sponsoring 
registrar or it has been implicitly approved or rejected by the 
registry. 


Example: 
A registrar cancels a previously requested domain transfer: 


C:transfer<crlf> 

C:-Approve:No<crlf> 
C:EntityName:Domain<crlf> 
C:DomainName:example.com<crlf> 

Ci.<erlt> 

S:200 Command completed successfully<crlf> 
SeSe rtf 


2.3. IPv6 Name Server Addresses 
Section 7 of RFC 2832 [2] has been updated to include support for 
name servers using IPv6 addresses. IPv6 addressing architecture is 
described in RFC 3513 [3]. This ABNF [4] grammar supplements the 
grammar defined in RFC 2832. 


; Lexical Tokens 


hexdigit = digit / %X41-46 / %x61-66 ; 0-9 / A-F / a-f 


doubleoctet = 1*4hexdigit 


docolon = doubleoctet colon 


colondo colon doubleoctet 
ip-address = ip-address-v4 / ip-address-v6 


; ipv4 addresses 
ip-address-v4 = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit 
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= doubleoctet ”7colondo 


Compressed form of IPv6 addresses 


Runs of zero-value octets are represented by ’:: 
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1*7docolon colon 
colon 1*7colondo 
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ip-address-v6-compressed =/ 3docolon 1*4colondo 
ip-address-v6-compressed =/ 4docolon 1*3colondo 
ip-address-v6-compressed =/ 5docolon 1*2colondo 
ip-address-v6-compressed =/ 6docolon colondo 


Internationalization Considerations 


This document does not introduce any internationalization 
considerations that are not already documented in RFC 2832 [2]. 


IANA Considerations 


This document does not introduce any IANA considerations that are not 
already documented in RFC 2832 [2]. 


Security Considerations 


This document does not introduce any security considerations that are 
not already documented in RFC 2832 [2]. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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